<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'A very limited selection',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2019/03/04.jpg" alt="Patches of ground with missing snow" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		I looked into what courses are available to me in coming terms, so I can re-plan what to do with my electives.
		The only available information on what courses are offered to people of my major is a bit of a mess, so I had to reformat it before I could learn hardly anything.
		The one thing I <strong>*could*</strong> learn was how many courses I was expected not to take from the list I was allowed to.
		I need to take forty course to graduate, so how many are available?
		It turns out there are only forty-four!
		So much for the concept of &quot;electives&quot;.
		I&apos;m stuck taking most of the either/or courses just to fill my elective credits.
		There&apos;s very little actual choice in what an be taken.
	</p>
	<p>
		After learning of that garbage, I started the obvious next step of reformatting the data into something I could process better in my scripts, to help me know what I had left to do and what choices I had left to make.
		Due to the school&apos;s blunder in my second term, I was only able to take one course that term instead of two, which et me back a term.
		When I take my final term&apos;s courses, I&apos;ll actually be up to forty-one courses, not forty, for that reason.
		So I need to decide which three courses I might not get to take, though as I discussed before, I&apos;m going to try to take them anyway as an experiment.
		It might not work out though, so I need to put off the course I&apos;m least interested in until last, and the second- and third-least interesting course for the second-to-last term.
		I made six simple deletions from the data, but before I could finish throwing out the useless data, after which I planned to rearrange the good data into a usable state, I realised that it&apos;d be easier to write a script to parse the messy data into something useful.
		For a one-time formatting, doing this by hand is the way to go, but which courses are offered may in fact vary by term.
		I&apos;m going to need to re-evaluate the list each term in case things change.
		Doing this by hand is a waste of time in the long run.
	</p>
	<p>
		After getting the course list parser and processor set up, so it would give me a list of required courses I have yet to take followed by a list of available electives, I easily found the course to put off until last: a course on art history.
		I&apos;m setting aside the rest of the decision-making for now though.
		I&apos;ve done enough work on this for today, and I can&apos;t even be sure the electives available next term reflect the electives that&apos;ll be available when I finally start taking electives.
		For all I know, the available electives change every term.
		That&apos;d really suck.
		Instead of just having a poor selection, I&apos;d also be relying on luck to get good courses.
	</p>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			You make a good point about sending confirmation to users via email.
			It can allow them to know the order went through, so they don&apos;t try a second time to place an order and end up paying twice and complaining to you.
			It took me a bit to see how that&apos;s a security practice though.
			If someone stole someone else&apos;s credit card and used it on a website, they&apos;d obviously not put that person&apos;s email address, both to avoid letting them know their card was being used and because they probably don&apos;t know that person&apos;s email address.
			However, if you&apos;re storing credit card information and not making users re-enter it when they place a new order, this practice would alert the account-holder if someone had gotten their login credentials and used them to place a purchase instead of the attacker getting their actual credit card details.
		</p>
	</blockquote>
</section>
END
);
